Code review

Found 2 issues:

1. TOCTOU race condition when updating latestBlockHash and latestBlockNumber. The check-then-set pattern uses three separate lock operations (Get, Set, Set), so two goroutines handling different peers can both pass the > check and interleave their writes, leaving hash and number mismatched (e.g., hash from block N, number from block N+1). This appears in handleBlockRangeUpdate, handleNewBlockHashes, and handleNewBlock. (CLAUDE.md says "Race Conditions: Run with -race flag during testing; protect shared state with mutexes or channels")

2. Batch proxy silently drops already-validated transactions. In handleBatchRequest, when the loop encounters an unsupported method mid-batch, it proxies the entire original batch and returns early — without broadcasting transactions that were already validated and collected in txs from earlier iterations. For example, a batch of [eth_sendRawTransaction, eth_getBalance] with proxy enabled would validate the transaction but never broadcast it. (CLAUDE.md says "Completeness: Data collection operations must fetch ALL requested data or fail entirely - never produce partial results")

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

Quality Gate passed

Issues
6 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud